-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple bug fixes to run parsec benchmark #189
Conversation
edcef2a
to
ee976b4
Compare
Clean solution for TLB priv level ! |
Change-Id: Ied973af5919b83c9fb88b66763958bbde11981d8
ee976b4
to
0a05b52
Compare
Change-Id: I986028fc43759dfa5d9c486687e971e931a730cb
Change-Id: Icfa64a99b9af5cb8fba58b45ce6712df46f2c012
No need to signal from L1D now Change-Id: I20db1f49e254adb518a8150b6c091358d21d2310
Previously, `fault->invoke()` updates priv immediately, TLB also translate using new priv. There still might be some instructions going to IEW at the moment. This is because interrupt traps when ROB is empty, but somehow these instructions are not in ROB yet. Such data race on processor PRIV causes mem accesses to bypass addr translation, thereby accessing a non-existent paddr, which would not be filtered out because GEM5 thinks they are PIO addrs. This fix makes TLB use old privilege mode until squashing signal is sent to IEW. Change-Id: I016e81069d090269afe4e40f14396cd9163f9ccd
@@ -835,7 +835,7 @@ Fetch::finishTranslation(const Fault &fault, const RequestPtr &mem_req) | |||
// If we have, just wait around for commit to squash something and put | |||
// us on the right track | |||
if (!cpu->system->isMemAddr(mem_req->getPaddr())) { | |||
warn("Address %#x is outside of physical memory, stopping fetch, %lu\n", | |||
DPRINTF(Fetch, "Address %#x is outside of physical memory, stopping fetch, %lu\n", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use "warn" can help us find the fetch stuck easier
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use "warn" can help us find the fetch stuck easier
But if on the speculative path, might it be too verbose?
@notlqr Did you observe a too verbose print here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some benchmarks produce too much warns here
No description provided.